📱 Scan the QR code below to install the build (arm64 only) for this PR.

If you can't scan the QR code you can install the build via this link: https://i.diawi.com/FX5i4P

Codecov Report

Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (da4825a) 70.12% compared to head (765cb97) 70.16%.
Report is 5 commits behind head on develop.

@@             Coverage Diff             @@
##           develop    #2194      +/-   ##
===========================================
+ Coverage    70.12%   70.16%   +0.03%     
===========================================
  Files         1335     1335              
  Lines        32781    32790       +9     
  Branches      6811     6812       +1     
===========================================
+ Hits         22988    23006      +18     
+ Misses        6515     6504      -11     
- Partials      3278     3280       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

This seems to be a lot more reliable than before 👍. Avatars do all eventually load although it can still take a while (several seconds) in larger rooms as it seems to wait for all avatars to be available before showing them. What would be the performance/UX implications of displaying them one at a time as they're available?
Is there any amount of caching for these images in EXA/rust-sdk? It seems to be slow after first loading the app each time but after that's basically instant.

This seems to be a lot more reliable than before 👍. Avatars do all eventually load although it can still take a while (several seconds) in larger rooms as it seems to wait for all avatars to be available before showing them. What would be the performance/UX implications of displaying them one at a time as they're available? Is there any amount of caching for these images in EXA/rust-sdk? It seems to be slow after first loading the app each time but after that's basically instant.

The issue that makes the images take so long to load is that, although we do have a cache for members in the Rust SDK, if I'm not mistaken (so take it with a grain of salt), the current Room.members() method from the Rust SDK only returns this cached version if it was loaded in the current session / for the current usage of the underlying Room object (I can't remember which one was right).

Technically we could call Room.getMember(userId) for each member at the moment, but it will only return something after this initial member loading has happened. We could call the profile endpoint if I'm not mistaken, but that wouldn't store the results in the Rust cache of room members.

So to improve this in the future I we have 3 options:

1. Make the Room.members() call return the currently cached members first, then the new ones If my understanding of the current behaviour is right.
2. Load members in a paginated way so we only load 100/200/500 at a time instead of thousands in large rooms.
3. Try to lazy load the avatar and display name using the profile endpoint, save them in an alternative cache instead of using the room members one.

Also, loading times on Android are a lot higher than on iOS partly because we have to map those thousand of items to plain Kotlin objects to ensure memory safety given the current UniFFi memory model for Kotlin. This should be fixed in the near future, which should make the app more performant overall, but until then this is what we have.

Thanks for taking the time to explain that!

Should we not fix this on the rust sdk instead? So the Receipt class should have the same logic than ProfileTimelineDetails

I believe we'd still have this caching issue, even if the SDK also re-emitted the current timeline with the updated read receipts: we'd still be asking the cache for an event with that id, and we'd use the cached one instead of the updated one containing the 'loaded' read receipts.

It seems like we want to go with option 1 for now:

Make the Room.members() call return the currently cached members first, then the new ones If my understanding of the current behaviour is right.

So it's probably better to wait until that is merged in the SDK side to also merge this PR.

Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud